Communication via the Transmission Control Protocol (TCP) and Internet Protocol (IP) is restricted to a single network path per connection, even though multiple network paths may exist between the peers of the connection. For instance, a mobile terminal may simultaneously be connected to a cellular radio access network, such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), or Long Term Evolution (LTE), network, and a Wireless Local Area Network (WLAN) or WiFi access network. Likewise, modern residential gateways, or home gateways, for deployment at customer premises oftentimes provide access to the Internet by means of cellular connectivity in addition to a wired access, such as a Digital Subscriber Line (DSL) service.
Multipath TCP (MPTCP) is an ongoing effort of the Internet Engineering Task Force (IETF) and aims at allowing an end-to-end TCP connection to use multiple paths to maximize resource usage and increase redundancy, thereby improving user experience (see, e.g., RFC 6824, http://tools.ietf.org/html/rfc6824). MPTCP extends TCP so that it presents a standard TCP interface to applications while in fact spreading data across several MPTCP subflows, i.e., separate TCP connections, typically using disjoint network paths. MPTCP is designed to be backwards compatible with plain TCP.
MPTCP is particularly useful in the scenarios described above. For instance, a mobile terminal using both a WLAN/WiFi access network and a cellular radio access network may experience a gain in throughput and connection reliability as the mobile terminal moves in or out of coverage without disrupting the end-to-end TCP connection. The problem of handover between MPTCP subflows is solved by abstraction in the transport layer, without any special mechanisms at the network or link level. Advantageously, when used in connection with residential gateways for providing Internet access, the Internet service provider may control the behavior of the residential gateway and thereby steer the traffic so as to optimize user experience and reduce cost. For instance, residential gateways may be configured to predominantly use DSL or any other wired access, whereas the cellular communications network is only used for excess traffic.
While MPTCP is designed as an extension to standard TCP, there are efforts to extend its use to the User Datagram Protocol (UDP) with the aim of offering multi-path support for also for UDP (see, e.g., “An MPTCP Option for Network-Assisted MPTCP Deployments: Plain Transport Mode”, IETF Internet-Draft, draft-boucadair-mptcp-plain-mode-06). UDP is one of the core members of the Internet protocol suite and is formally defined in RFC 768. It uses a simple connectionless transmission model with a minimum of protocol mechanism. UDP has no handshaking dialogues, and thus exposes the application utilizing UDP to any unreliability of the underlying network protocol. There is no guarantee of delivery, ordering, or duplicate protection. With UDP, a peer can send messages, also referred to as datagrams, to other peers on an IP network without prior communications to set up special transmission channels or data paths. UDP is suitable for purposes where error checking and correction is either not necessary or is performed at a higher level in the protocol stack. Time-sensitive applications often use UDP because dropping packets is preferable to waiting for delayed packets, which may not be an option in a real-time system. If error correction needed at the network interface level, an application may, e.g., use TCP or the Stream Control Transmission Protocol (SCTP) which are designed for this purpose.
The basic idea put forward in draft-boucadair-mptcp-plain-mode-06 is to tunnel UDP packets inside MPTCP packets over an MPTCP connection. This mode of operation of MPTCP is referred to as “plain mode” or “plain transport mode”. In view of the fact that transport control functions like ordered transfer, retransmission of lost packets, flow control, and congestion control, which are commonly used in TCP are absent in UDP, draft-boucadair-mptcp-plain-mode-06 proposes that such functionality is disabled in plain transport mode and that enabling such features is deployment and implementation-specific.